Subject: HPR CP specification

From: Mike Evans <[email-masked]>
Date: Fri, 21 Apr 95 14:20:00 BST

The following is our initial tranche of questions and points on the changes 
in the HPR-3 specification.  As we progress integrating the changes (and 
when Matthew gets back from his holiday next week!) we will undoubtedly have 
further questions, but since we are only a few weeks away from the AIW I 
thought it best to send these now.

Mike Evans (DCL)

 ----------------------------------------------------------

NCE Instance Identifiers (section 9.8)
 --------------------------------------

I understand the problem NCEIIs are trying to solve, but it looks like they 
offer a very limited solution.  In particular, they don't work if either

 -  the second session is not activated through the same two RTP capable
   nodes,  for example, because the deactivated node is permanently 
disabled,
   or

 -  the re-IPLed node changes its NCE (not changing NCEs over IPLs is
   recommended, not mandatory).

The problem can be restated as a requirement for a path-switching node to 
detect, within a reasonable space of time, that the partner RTP node has 
been deactivated (and so has no record of the RTP connection).

We therefore propose an alternative solution as follows.

1)  If an RTP-capable node receives a Route Setup request triggered by a 
path
    switch where it is indicated as the destination, but where the 
destination
    NCE is unknown, it fails the Route Setup with a unique sense code
    indicating the fact that the NCE was unknown.

2)  If an NCE receives a NLP containing an unknown TCID, a switching
    information segment, but no connection setup segment, he returns a
    connection fault segment indicating this fact using the RANR in the
    switching information segment, the received TCID and a CQF containing
    its network identifier, network name and NCE label.

3)  If an RTP node is attempting to path switch, and receives this 
connection
    fault segment, it immediately terminates the RTP connection (failing any
    sessions using the connection).

This solution results in the path-switching node deactivating the connection 
on the first path switch retry after the partner node re-IPLs and reconnects 
into the network (give or take topology propagation delays), which should be 
sufficiently fast for most implementations.

This solution has several advantages over NCEIIs.

 -  It is simpler and easier to implement than NCEIIs (which is important 
this
   close to CP status).

 -  It works with nodes that do not preserve NCE labels across IPLs.

 -  It works in many cases where the second session does not pass through
   the same two nodes.

However, it may still not work

 -  if the time between path switch attempts is large (which should therefore
   not be recommended)

 -  if the partner RTP node does not re-IPL (ie. is permanently disabled).

Unfortunately, we can't come up with a solution general enough to work if 
the partner RTP node is permanently disabled.  Aren't session limits 
wonderful!

Persistent ANR Labels (section 7.1.3)
 -------------------------------------

This section seems to 'sit on the fence' and not recommend either of the two 
proposed solutions to the ANR misrouting problem. Is either solution 
recommended, mandatory, or is it an implementation option? If it is intended 
as an implementation option, then the specification should say so.

We also propose a third, hybrid, solution to the problem, which ages ANR 
labels when the link is deactivated, but if the link is reactivated during 
the ageing period, uses the same label for that link.  This has the benefits 
of both the proposed solutions (if the aging period is sufficiently large) 
with none of the disadvantages.

The specification should also note some of the possible serious consequences 
of ANR misrouting (since in most of the obvious cases, the connection just 
path switches).  The worst case I could come with is when, in problem 1, 
Link A and Link B are parallel links to the same adjacent node, but Link A 
is secure and link B is non-secure.  Once the misrouting happens, no 
path-switch will occur, and potentially sensitive data is being sent over a 
non-secure link!

Route Setup
 -----------

The HPR-1 spec. describes how a new RTP connection can make use of the 
routing information associated with an existing RTP connection with the same 
RSCV, thus avoiding Route Setup.  This is shown as condition B in figure 9-3 
(page 9-7).

The HPR-3 spec. shows no such shortcut in the corresponding diagram (figure 
9-6, page 9-14), although there is no reference to a change in the preface. 
The "session initiation logic" section (figure 9-7, pages 9-18 and 9-19) is 
consistent in that it shows Route Setup always being performed when a new 
RTP connection is set up.

The HPR-2 spec. is consistent with the HPR-3 spec., but there is no mention 
of this change in the change pages of HPR-2 or HPR-3.

Has this option really been removed?  Is it because the COS/TPF can now be 
changed on the Route Setup reply (by an intervening border node)?  If that 
is the case, isn't it still ok to avoid the route setup if the route does 
not path through a border node (easily verified by looking at the RSCV)?